-
Notifications
You must be signed in to change notification settings - Fork 832
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DatePicker] Don't run onChange if same date selected #1967
Conversation
This pull request is being automatically deployed with Vercel (learn more). |
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a failing test case with testing-library that demonstrate the fix? Thanks
Also, I believe we should test all the components, date picker, date time picker, time picker, etc.
I'll get to it. Sorry, it's my first opensource contribution :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think overall logic is not correct, please add a test (with testing library) that confirms desired behavior
if (!valueManager.areDaysEqual(utils, newDate, pickerDate)) { | ||
setPickerDate(newDate); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (!valueManager.areDaysEqual(utils, newDate, pickerDate)) { | |
setPickerDate(newDate); | |
} | |
if (valueManager.areDaysEqual(utils, newDate, pickerDate)) { | |
return; | |
} | |
setPickerDate(newDate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing something but wouldn't this run only if you select the same date?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you are right but we still doesn't need to update the state.
Another question – what for TimePicker and DateTimePicker? I think overall we need to add this check to the Calendar
component.
@tdranv Did you have the time to look at the feedback from the review? :) |
I did but I'm having trouble with what you meant by "Could you add a failing test case with testing-library that demonstrate the fix?". Can you elaborate a little more on that? |
@tdranv firstly please make this check on the So proposed diff will be this: --- a/lib/src/views/Calendar/Day.tsx
+++ b/lib/src/views/Calendar/Day.tsx
@@ -179,7 +179,7 @@ const PureDay: React.FC<DayProps> = ({
};
const handleClick = (event: React.MouseEvent<HTMLButtonElement>) => {
- if (!disabled) {
+ if (!disabled && !selected) {
onDaySelect(day, 'finish');
} And also please add a new test case to this file: |
@tdranv Sure, the idea is that for a test to be relevant, it has to fail without the fix, otherwise we are testing something that already works. |
I seem to have broken something else. I will take a look at it later. Thanks for being patient with me. :) |
From what I am seeing it looks like this behavior is not suitable for DateRangePicker. We must have the ability to select the same day for start and end. (#1759) What I propose: add new prop
|
@dmtrKovalenko Regarding #1759, what about we solve it with #1759 (comment)? For the date range picker, I think that the equivalent fix would be that if the same range is selected, no change event is fired. |
I added the flag you suggested @dmtrKovalenko. First, once again, thank you for being patient with me. I like Material UI a lot and wish to be part of it :) Here are the issues are encountered, as a first-time contributor:
Anyway, working on this (despite it being such a small issue) is fun! Thanks for your guidance :) |
/> | ||
); | ||
|
||
fireEvent.click(screen.getByLabelText('Choose date, selected date is Jan 1, 2018')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I side note, I wonder if the asserting here isn't too brittle. What happens if we change the formation or the value? Would it be possible to query an element with role button instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I too think that this approach to querying can be brittle. But also fixing it should probably part of a separate issue/pull request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, right, a different pull request would make sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks solid
@@ -123,6 +123,11 @@ export interface DayProps extends ExtendMui<ButtonBaseProps> { | |||
* @default false | |||
*/ | |||
disableHighlightToday?: boolean; | |||
/** | |||
* Allow selecting the same date (fire onChange even if same date is selected). | |||
* @default false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eps1lon This change makes me wonder. On the main repository, we don't mention the default value in the TypeScript definitions, we have a tool that extracts them from the source.
Here, the upside is that we get the information right in the editor:
But it can get quickly out-of-sync. What do you think about the tradeoff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea. I think we could statically verify if the default value matches. Though I wouldn't worry about it too much at first. In the end default values will rarely change in SemVer patches or minors because they're very likely breaking changes.
I don't remember how we extract default values but if we extract them statically then we can also match them against TS types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tdrandv Thanks, everything looks nice except this commit. Can you please revert it and we could merge it 💪
docs/pages/guides/css-overrides.mdx
Outdated
Add the following to a TypeScript declaration file in your project, such as `overrides-mui.d.ts`: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add the following to a TypeScript declaration file in your project, such as `overrides-mui.d.ts`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ops. Should be good now :)
Requested changes were done
@tdranv For the tests, do you think that it would make sense to cover the other components, TimePicker, DateRangePicker, DateTimePicker? |
Hm, I believe no for TimePicker. As far as DateRangePicker, a user can select the same date if the start and end dates are the same, as @dmtrKovalenko pointed out in a previous comment. |
What should happen if a end-user uses the date range picker and choose the same range than previously? Should it fire a change event or not? |
I probably did not say that correctly. What I mean was that a end-user can pick the same date for the start and end date. As far as your question: I believe it should not fire the event. |
@tdranv Ok cool. It was a great first pull request on Material-UI 👌🏻. Thank you for working on it! |
@tdranv If you would like to keep helping without diving too deep in the complexity of the components, there is ongoing work around unifying the codebase. For instance, mui/material-ui#21758 was recently merged on the main repository, it would be perfect if we could enforce the exact same eslint configuration here. I have started a couple of iterations already (doing it in small chunks), I'm doing that for an hour or two during the weekend. But if you want to speed things up, feel free too. Related to #1930. |
Sure. I will have a look at it over the weekend. :) |
Fixes #1652
For some reason the function
areValuesEqual
invalueManager
was returning false when checking if two dates are equal (when in fact they were). This only happened the first time you choose the current value. If the picker's value was, let's say, 08/07/2020 and you selected it again, it would return false but if you select it a second time, it would return true.To solve it, I added another function -
areDaysEqual
.